[ 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
6 September 2002 (06.09.2002) 




PCT 



(10) International Publication Number 

wo 02/069099 A2 



(51) International Patent Classification^: G06F 

(21) International Application Number: PCTAJS02/05667 

(22) International Filing Date: 25TeBfuary 2002 (25.02.2002) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 
09/793,475 



26 February 2001 (26.02.2001) US 



(71) Applicant: ALARIS MEDICAL SYSTEMS, INC. 

[USAJS]; 10221 Wateridge Circle, San Diego. CA 
92121-2733 (US). 

(72) Inventors: EGGERS, Philip, N.; 15238 Midland Road, 
Poway, CA 92064 (US). SCHLOTTERBECK, David, L.; 
12 Hermitage Lane, Laguna Niguel, CA 92677 (US). VAN- 
DERVEEN, Timothy, W.; 13571 Summit Circle, Poway, 
CA 92064 (US). COFFMAN, Damon, J.; 4301 Hermosa 
Way, San Diego, CA 92103 (US). 



(74) Agents: KOHLER, Thomas, D. at al.; Pennie & Edmonds 
LLP, 1155 Avenue of the Americas, New York. NY 10036 
(US). 

(81) Designated States (national): AE, AG, AL, AM. AT. AU. 
AZ, BA, BB, BG. BR, BY, BZ, CA, CH, CN, CO, CR, CU, 

CZ, DE, DK, DM, DZ, EC, EE, ES, n, GB, GD, GE, GH, 
GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, 
LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, 
MX, MZ, NO, NZ, OM, PH, PL, PT. RO, RU, SD. SE, SG. 
SI, SK, SL, TJ, TM, TN, TR, TT, TZ, UA, UG, UZ, VN. 
YU. ZA. ZM. ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM. 
KE, LS, MW. MZ, SD. SL, SZ, TZ, UG, ZM. ZW), 
Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), 
European patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, 
GB, GR, IE, IT, LU, MC, NL, PT, SE, TR), OAPI patent 
(BF, BJ, CF, CG. CI. CM, GA, GN, GQ. GW, ML, MR. 
NE, SN. TD. TG). 

Published: 

— without international search report and to be republished 
upon receipt of that report 

[Continued on next page] 



(54) Title: SYSTEM AND METHOD FOR MANAGING PATIENT CARE 



< 

as 

ON 
ON 

O 



1 CPU 1 1 Printer | 


Bar Code 




1 








1 




Network 
Connection 




1 User I/O 1 
Pharmacy System 





Billing 



HospHal 
Information 
System 
Server 



^30 



Laboratory 



Supply 



Decision 
Support 



40 

-42 



48 
*46 



Funct. 
Unft 



Fur)cl. 
Unit 

□ 



ROM 



APM 



[ CPU I 



^1 



NetworK 

; — , Connection 

' T 



RAM I 



-56 I : 

[Disk J [user VP 



Aox. fntertace 
1 



5^ 

3arCo5e 



Funct. 
Unit 

□ 

I ROM) 



RAM 



C50 



Funct 
Unit 

□ 

1 ROM 1 
r RAM i 



12 



(57) Abstract: The present invention is directed to a system and method for providing care to a patient comprising a patient care 
device having a number of configuration databases stored in a memory in the device. Each configuration database preferably includes 
protocols, operating limits, rule sets and/or operating features that collectively define an operating environment, or personality, of the 
device. Selection of a specific configuration database preferably is based at least in part upon patient-specific information obtained 
from any location in a distributed hospital network. Examples of such patient-specific information include patient are or size, patient 
medical characteristics, a location of the patient or a location of the care device. In a preferred embodiment, programming a patient 
care device to deliver a drug to a patient entails activating a configuration database and scanning a machine -readable drug label 
identifying a particular protocol stored in the activated database. The selected protocol includes default parameters for delivering the 
drug, and the label optionally includes instructions for deviating fh>m the default protocol. 
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SYSTEM AND METHOD FOR MANAGING PATIENT CARE 

Phillip Eggers 
David Schlotterbeck 
Timothy Vanderveen 
Damon Coffman 

RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. patent application serial no. 
09/379,212, filed August 23, 1999; which is a continuation of U.S. Patent No. 
5,941,846, entitled "Method and Apparatus for Power Connection in a Modular 
5 Patient Care System", filed June 9, 1997; which is a continuation-in-part of U.S. 
Patent No. 5,713,856, entitled "Modular Patient Care System", filed March 13, 1995. 
These related applications are herein incorporated by reference in their entireties. 

TECHNICAL FIELD 

10 The present invention relates generally to a system and method for managing 

patient care in a heath care facility, and in particular to a system and method for 
integrating information firom a distributed network to alter the operating characteristics 
of a patient care device. 

15 BACKGROUND OF THE INVENTION 

Much attention in the health care industry has been placed on reducing 
the incidence of medication dosing errors and improving overall quality of patient 
care. Often medication dosing errors occur because a patient receives the wrong 
medication, a wrong dosage of the correct medication, the correct dosage of the correct 

20 medication at the wrong time, or the medication has harmful interaction with other 
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drugs. Recent advances in the health caie field have attempted to address these 
problems and to enhance efficiency and quality of patient care. 

Many drugs are dispensed for patient use at or close to the point of care 
using programmable infusion pumps such as those disclosed by U.S. Patent No. 
5 5,713,856 to Eggers et al. and U.S, Patent No,5,041,086 to Koenig et al., both of 
which are incorporated herein by reference, Eggers et al. discloses a modular patient 
care system capable of providing therapy to a patient and monitoring patient condition. 
The system of Eggers utilizes a central control module to control and monitor a 
number of functional modules, including one or more infusion pumps and patient 
10 naJ>fitoring devices. 

, Most hospitals today have a pharmacy equipped with a computerized 
system for entering, preparing, and tracking prescriptions, managing dmg inventory, 
checking for drug incompatibilities, and printing prescription orders and labels. 
Typically, one or more medication infusions to be administered to a patient are 
15 prescribed by the patient's physician. The pharmacy prepares the infusion solution 
according to the physician's prescription and places the solution in an IV bag, syringe 
or other container. A printed label identifying the container contents, the patient to 
whom the medication is prescribed, the prescribing physician, delivery instructions 
and/or other information regarding the prescription. The label is generally typed or 
20 printed in human readable characters. In some instances, bar codes are used to encode 
information on the label. 

After a label is affixed, the container is transported to the patient's 
location and operatively attached to a bedside infusion pump system, such as that 
disclosed by Eggers et al. A nurse or other care provider then programs the infusion 
25 system with drug delivery data from the label, typically by manually entering infusion 
parameters using a keyboard or a keypad. Alternatively, some systems seek to reduce 
data entry errors by incorporating a bar code reader that scans coded data into the 
pump system from the drug label or from a prescription order. The data may include, 
for example, rate of infusion, total volume to be infused (VTBI) and, in multichannel 

2 
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or modular systems such as that described by Eggers et aL, which charaiel or pump 
module is to be used. 

U.S. Patent No. 5,153,827 to Coutre et al. discloses a system for 
providing an infusion apparatus with medication infusion parameters from a central 

5 pharmacy database. Infusion delivery parameters for a particular treatment are printed 
from the central pharmacy database on a machine-readable labels, which are then 
carried to the patient location and scanned into the bedside infusion apparatus. The 
system of Coutr6 requires that all information used to program a pump is either 
scanned from a machine-readable label or entered manually by the user. Thus, the 

10 infusion systems of Coutr6 do not utilize information from other sources within the 
hospital or within the system itself. 

U.S. Patent No. 5,781,442 to Engleson et al. discloses a patient care 
. management system comprised of a network of computers having a variety of input 
and output devices for receiving patient data and for generating or displaying reports. 

15 The disclosed system monitors ongoing administrations of care to patients and 

automatically updates records and provides alarms when necessary. In an example of 
use, patient and drug identification information are scanned into a bedside terminal 
and conununicated to a central computer, where the data are processed The central 
computer then sends operating parameters to the terminal and the terminal programs 

20 an infusion pump in accordance with the oi>erating parameters. 

In spite of recent advances in the art, there remains a need in the art for 
a system that facilitates efficient and accurate programming of a medical treatment 
device while ensuring that the prescribed treatment conforms with institutional and 
departmental guidelines with respect to a patient in a particular location and/or with 

25 particular characteristics. 



SUMMARY OF THE INVENTION 

The present invention generally involves the movement of patient 
information from a variety of sources such that the patient receives a better quality of 
30 care, the care providers' assets are utiKzed more efficienfly and labor costs are reduced 
through the automation of some processes now done manually. The means of data 

3 
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transfer is typically done within a network, or network of networks, with some data 
entering and exiting through portals which convert data formats. A preferred 
embodiment of the present invention is a modular patient care device connected to a 
hospital network, wherein the capabilities and operating characteristics of the device 

5 are altered as a function of its location within the network. 

According to the invention there is provided a patient care system, 
comprising a patient care device and means for transferring patient-specific 
information to the device. The device includes a memory for storing a plurality of 
configuration databases, each of which comprises a plurality of distinct groups of 

10 device operating parameters. Transferring patient-specific information to the device 
enables selection of a specific configuration database fixim the plurality of 
configuration databases, based at least in part on the patient-specific information. The 
patient care system of the present invention also preferably includes a computer 
network and means for communicating between the device and the network. 

15 Still further according to the invention there is provided a method of 

program mi ng a patient care device to deliver a substance to a patient, comprising 
printing a coded label, said label including a protocol pointer identifying a first . 
protocol for delivering the substance to flie patient; attaching the label to a container 
holding the substance; transporting the container to the patient care device; entering 

20 the pointer into the patient care system, the patient care system including the first 

protocol in a memory; and prognunming a functional unit of the patient care system to 
deliver the substance to the patient in accordance with the first protocol. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 For a better understanding of the nature and details of the invention, 

reference should be made to the following detailed description taken in conjunction 
with the accompanying drawings, in which: 

FIG. 1 is a schematic diagram of a patient care management system 
according to the present invention; 
30 FIG. 2 is a schematic diagram of an interface unit according to the 

present invention; 

4 
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HG. 3 is a schematic diagram illustrating a configuration database 
according to the present invention; 

FIG. 4 is a block diagram illustrating a number of different infusion 
types supported by the interface unit of the present invention; 
5 FIG. 5 illustrates the process steps for programming an infusion system 

to perform a particular infusion protocol in accordance with one embodiment of the 
present invention; 

FIG. 6 is a schematic diagram of an altemative embodiment of the 
patient care management system of the present invention; and 
10 FIG. 7 illustrates the process steps used to relate a programming 

module with a patient, in accordance with one embodiment of the present invention. 

like reference numerals refer to corresponding parts throughout the 
several views of the drawings. 

15 DESCRIPTION OF THE INVENTION 

FIG. 1 is a general illustration of a patient care system in accordance 
with one embodiment of the present invention. In FIG. 1, a patient care device 12 is 
connected to a hospital network 10 including a pharmacy management system 34 and a 
hospital information system server 30. Each element 12, 30 and 34 is coimected to 

20 network 10 by a transmission channel 32. Transmission channel 32 is any wired or 
wireless transmission channel, for example a 802.11 wireless local area network 
(LAN). In a preferred embodiment of the present invention, network 10 also includes 
computer systems located in various departments throughout a hospital. For example, 
network 10 of FIG. 1 optionally includes computer systems associated with an 

25 admissions department 36, a billing department 38, a biomedical engineering 

department 40, a clinical laboratory 42, a central supply department 44, one or more 
unit station computers and/or a medical decision support system 48. 

Patient care device 12 preferably comprises a system similar to that 
described in U.S. Patent No. 5,713,856 to Eggers et al., which is incorporated herein 

30 by reference. Alternatively, other patient care devices, such as pumps, physiological 
monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient 

5 
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monitors), therapy devices, and other drug delivery devices may be utilized according 
to the teachings set forth herein. Patient care device 12 preferably comprises an 
advanced programming module 14, also referred to as interface unit 14, connected to 
one or more functional modules 16, 18, 20, 22. Interface unit 14 includes a central 
5 processing unit (CPU) 50 connected to a memory, e.g. random access memory (RAM) 
58, and one or more interface devices such as user interface device 54, a coded data 
input device 60, a network connection 52, and an auxiliary interface 62 for 
communicating with additional modules or devices. Interface unit 14 also preferably, 
although not necessarily, includes a maui non-volatile storage unit 56, preferably a 
10 hard disk drive, for storing software and data and one or more internal buses 64 for 
interconnecting the aforementioned elements. 

In a typical embodiment, user interface device 54 is a touch screen for 
displaying information to a user and allowing a user to input information by touching 
defined areas of the screen. Alternatively, user interface device 54 could include any 
15 means for displaying and inputting information, such as a monitor, a printer, a 

. keyboard, softkeys, a mouse, a track ball and/or a light pen. Coded data input device 
60 is preferably a bar code reader capable of scaiming and interpreting data printed in 
bar coded format. Altemadvely, data input device 60 could be any device for entering 
coded data into a comiputer, such as devices for reading a magnetic strips, PCMCIA 
20 smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog 
or digital storage media. Other examples of data input device 60 include a voice 
activation or recognition device or a portable persona] data assistant (PDA). 
Depending upon the types of interface devices used, user interface device 54 and 
coded data input device 60 may be the same device. Alternatively, although data input 
25 device 60 is shown in FIG. 1 to be disposed within interface unit 14, one skilled in the 
art will recognize that data input device 60 may be integral within pharmacy system 34 
or located externally and communicating with pharmacy system 34 through an RS-232 
serial interface or any other appropriate communication means. Auxiliary interface 62 
is preferably an RS-232 conununications interface, however any other means for 
30 conununicating with a peripheral device such as a printer, patient monitor, infusion 

6 
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pump or other medical device may be used without departing from the scope of the 
invention. 

Network connection 52 is preferably a direct network connection such 
as a Tl connection, an integrated services digital network (ISDN) connection, a digital 
5 subscriber line (DSL) modem or a cable modem. Alternatively, any direct or indirect 
network connection may be used, including, but not limited to a telephone modem, an 
MBB system, an RS232 interface, an auxiUary interface, an optical link, an infrared 
link, a radio frequency Unk, a microwave link or a WLANS connection. 

Functional modules 16, 18, 20, 22 are any devices for providing care to 
10 a patient or for monitoring patient condition. In preferred embodiment of the present 
invention, at least one of functional modules 16, 18, 20, 22 is an infusion pump 
module such as an intravenous infusion pump for delivering medication or other fluid 
to a patienL For the purposes of this discussion, functional module 16 is an infusion 
pump module. Each of functional modules 18, 20, 22 may be any patient treatment or 
15 monitoring device including, but not limited to, an infusion pump, a syringe pump, a 
PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse 
oximeter, an EKG monitor, an EEG monitor, a heart rate monitor or an intracranial 
pressure monitor. Altematively, functional module 18, 20 and/or 22 may be a printer, 
scaimer or any other peripheral input/output device. 
20 Each functional module 16, 18, 20, 22 communicates directly or 

indirectly with interface unit 14, with interface unit 14 providing overall monitoring 
and control of device 12. Li a preferred embodiment, functional modules 16, 18, 20, 
22 are connected physically and electronically in serial fashion to one or both ends of 
interface unit 14 as shown in HG. 1 and as detailed in Eggers et al. However, one 
25 skilled in the art wiU recognize that there are other means for connecting functional 
modules with the interface unit may be utilized without departing from the scope of 
the invention. It will also be appreciated that devices such as pumps or monitors that 
provide sufficient programmability and connectivity may communicate directly with 
the network without a separate interface unit. As described above, additional medical 
30 devices or peripheral devices may be connected to patient care device 12 through one 
or more auxiliary interfaces 62. 

7 
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Each functional module 16, 18, 20, 22 typically includes module- 
specific components 76, a microprocessor 70, a volatile memory 72 and a non- volatile 
memory 74 for storing information. It should be noted that while four functional 
modules are shown in figure 1, any number of devices may be connected directly or 
5 indirectly to central computer 14. The number and type of functional modules 
described herein are intended to be illustrative, and in no way limit the scope of the 
present invention. Module-specific components 76 include any components necessary 
for operation of a particular module, such as a pumping mechanism for infusion pump 
module 16. 

10 While each fimctional module is typically capable of a least some level 

of independent operation, interface unit 14 monitors and controls overall operation of 
device 12. For example, as will be described in more detail below, interface unit 14 
provides programming instructions to the functional modules 16, 18, 20, 22 and 
monitors the status of each module. 

15 In a preferred embodiment of the present invention, patient care device 

12 is capable of operating in several different modes, or personalities, with each 
personality defined by a configuration database. A particular configuration database is 
selected based, at least in part, by patient-specific information such as patient location, 
age, physical characteristics, or medical characteristics. Medical characteristics 

20 include, but are not limited to, patient diagnosis, treatment prescription, medical 
history, medical records, patient care provider identification, physiological 
characteristics or psychological characteristics. As used herein, patient-specific 
information also includes care provider information (e.g., physician identification) or a 
patient care device's 10 location in the hospital or hospital computer network. Patient 

25 care information may be entered through interface device 52, 54, 60 or 62, and may 
originate from anywhere in network 10, e.g. from pharmacy 34, admissions 36, 
laboratory 42, etc. 

Data to and from the various data sources can be converted into 
network-compatible data with existing technology, and movement of the information 

30 between the medical device and network can be accomplished by a variety of means. 
For example, patient care device 12 and network 10 may communicate via automated 

8 
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interaction and/or manual interaction. Automated interaction may be continuous or 
intermittent and may occur through direct network connection 54 (as shown in HG. 1), 
or altematively through RS232 links, MIB systems, RF links such as BLUETOOTH 
(Amtel Corp., San Jose, CA), TR links, WLANS, digital cable systems, telephone 

5 moden[is or other conomunication means. Manual interaction between patient care 
device 12 and network 10 involves physically transferring, intermittently or 
periodically, data between systems using, for example, user interface device 54, coded 
data input device 60, bar codes, computer disks, portable data assistants, memory 
cards, or any other media for storing data. Preferably, the communication means is 

10 bidirectional with access to data from as many points of the distributed data sources as 
possible. Decision-making can occur at a variety of places within network 10. For 
example, and not by way of limitation, decisions can be made in HIS server 30, 
decision support 48, hospital department or unit stations 46, or within patient care 
device 12 itself. 

15 Referring to FIG. 2, in a preferred embodiment of the present invention, 

interface unit 14 of patient care device includes a plurality of configuration databases 
200, 202, 204 and 206. The configuration databases are preferably stored in memory 
56 of interface unit 14; however one or more databases may be stored within a 
functional module 16, 18, 20, 22. One skilled in the art will understand that, while 

20 memory 56 is preferably an internal hard disk, any permanent or removable storage 
media including, but not limited to, CD-ROM, EEPROM, diskette, tape, external hard 
disk, memory card, flash memory, etc. may be used. Optionally, portions of 
configuration databases 200, 202, 204, 206 may be stored in volatile memory such as 
RAM 58. 

25 Each configuration database 200, 202, 204, 206 preferably includes a 

unique database identifier, or pointer, 210, 212, 214, 216, for identifying the respective 
database. Each database 200, 202, 204, 206 includes a plurality of fields which define, 
for example, available treatment protocols, drag library information, module operating 
linndts, rule sets, device features and possibly other information for defining a 

30 particular operating parameters for patient care device 12. Each configuration 

database 200, 202, 204, 206 defines a specific operating environment, or personality, 

9 
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for patient care device 12. The individual configuration databases may be treatment 
location specific (e.g. intensive care unit [ICU], neonatal intensive care unit [NICU], 
pediatrics, oncology, etc.), disease state specific (intracranial pressure management, 
bone marrow transplant, etc.), user specific (LPN, RN, physician, etc.), or created by 
5 any other rationale. For example, according to one embodiment of the present 

invention, when patient care device 12 is located in the ICU it utilizes configuration 
database 200, and when device 12 is located the NICU it utilizes configuration 
database 202. Each database 200 and 202, respectively, contains particular operating 
parameters, treatment protocols, features etc. that configure device 12 for use with 
10 patients in that imit of the hospital. 

It should be noted that while FIG. 2 shows that each database includes 
the same categories and types of information, the databases may vary considerably in 
terms of the types and amounts of information they contain. Each of the various 
configuration databases, when selected, at least in part defines the operating 
15 environment of device 12 and includes a number of protocols or groups of default 
operating parameters. :: 
HG. 3 is a more detailed representation of a sample configuration 
database 204 according to the present invention. Configuration database 204 includes 
a protocol module 230 comprising a plurality of protocols 232, 234, 236, 238, 240. 
20 Each protocol includes a plurality of fields of default operating parameters. In some 
cases an infusion protocol may include a complete detailed infusion instmction with 
all of the default parameter values defined. Other infusion protocols may have 
partially defined parameters with additional data entry required by the user at the point 
of care. For example, protocol A 232 of FIG. 3 includes fields of default operating 
25 parameter values and other data for controlling a medication infusion pump. The 
fields of this example include drug name 300, concentration 304, container size(s) 
308, nominal dose rate 312, initial bolus 316, maximum dose rate 320, mimmum dose 
rate 324, maximum cumulative dose 328, drug incompatibility 332 and an ID field, 
record pointer 336, for identifying or "calling*" tiie protocol record. Each field 
30 typically includes stored default parameter values that collectively define a specific 
infusion protocol. Some fields, such as Drag Incompatibility 332, include a reference 

10 
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or link to another database or drug library containing relevant information. Such 
references to conunonly used data libraries allow data to be shared betwe^pn protocols 
and/or configuration databases to avoid duplicate storage and entry and to allow 
efficient updating of database information. Similarly, all protocols need not be stored 
5 within each configuration database. Rather, protocols from different configuration 
databases may be saved in a master database or library, with each individual 
configuration database containing reference links to particular protocols stored in the 
library. Such an arrangement is advantageous because it avoids duplicate storage of 
identical protocols and facilitates updating of library information. 
10 When such a protocol is selected certain information must be provided. 

For example, device 12 may query the network to automatically obtain data such as 
patient weight fix>m the patient's electronic records in admissions 36, critical dosage 
parameters from pharmacy system 34 and double check with laboratory 42 for recent 
test results which may contraindicate the prescribed medication. A double check with 
15 pharmacy system 34 of information coded on the drug prescription label also may be 
automatically performed. Alternatively, the user may enter data such as the patient 
weight and total dosage direcdy into the device, and confirms the automatically 
selected parameters. In one embodiment of the invention, information in a drug 
specific protocol is a superset of the information in the "drag library". Consequently, 
20 if the user selects a dmg name, then certain parameters in the record are applied. Such 
parameters would typically include the drug nanfie, delivery rate limits, units of 
delivery, possibly concentration and container size. The user would enter or scan in 
missing data such as patient weight, drug amount, diluent volume, dosage rate, total 
dosage and confirm the automatically selected parameters as prompted, 
25 Different protocols typically include different fields and/or different 

parameter values. Thus, Protocol B 234 might include additional fields compared to 
Protocol A 232, where the additional fields define instructions and/or parameters for 
implementing one or more different infusion types such as primary/secondary infusion, 
multichannel coordinated infusion and multidose protocols (see FIG. 4). 
30 Alternatively, Protocol B 234 could include the same fields as Protocol A 232, and 
differ only in terms of one or more parameter values in one of the fields. For example, 

11 
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both protocols could be for infusion of the drug dopamine, where one protocol has a 
concentration 304 value of 400mg/250niL while the other has a concentration 304 
value of 800 mg/mL. 

Referring again to FIG. 3, the Rule Sets module 250 of database 204 

5 includes rules and/or algorithms that may be used to help define particular parameters 
within a database. For example. Rule Sets module 250 could include an algorithm that 
modifies the maximum allowable infusion rate or some ottier parameter based upon 
data obtained from other sources in network 10, such as patient age, body weight or 
medical history from Admissions 36 or test results from Laboratory 42, Other rule sets 

10 in the Rule Sets module 250 may provide warnings or recommendations upon the 
occurrence of particular events within pump module 16, such as occlusion of the 
infusion line. 

Still other rale sets within module 250 may contain algorithms that 
utilize measurements from one or more functional modules to modify operation of 

15 another functional module. For example, module 250 may contain a rule set that 
monitors blood pressure and intracranial pressure in a head trauma patient and 
calculates resulting perfusion pressure. The system then notifies the user when 
perfusion pressure falls outside of a defined range and recommends adjusting infusion 
rate of a therapeutic agent to increase blood pressure or to decrease intracranial 

20 pressure. 

The Pump Limits module 260 of database 204 contains information that 
defines the overall operating limits of infusion pump module 16 and other pump 
devices, if any, attached to interface unit 14. The Pump Limits module 260 typically 
includes at least three fields. Air In Line (AIL) Limits 262, Max Rate 264, and Max 

25 Pressure 268, Because the Pump Limits module 260 of each configuration database 
200, 202, 204, 206 potentially contains different parameters and values, module 260 
helps define the operating characteristics or mode in which device 14 operates when a 
particular configuration database 200, 202, 204, 206 is active. 

AIL Linndts 262 defines an allowable limit for the amount of air in an 

30 infusion line connected to a patient Allowable AIL Limits may differ for particular 
patients or particular locations in the hospital. For example, an allowable limit of 

12 
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50>uL may be set for pediatric patients, while a limit of 100-200 fjCL is used for general 
adult patients and 500 fJL for operating room and/or trauma patients. 

Max Rate 264 defines the maximum allowable infusion rate for an 
infusion pump operating under that particular configuration database 20. Again, the 
5 defined Max Rate 264 values may differ among patient class, attributes, location, etc. 
For example, the maximum rate for delivering heparin to pediatric patients may be set 
at 10 units/Kg/hr, while adult patients have a limit of 500-1000 units/hr. 

Feature Enable/Disable module 270 of configuration database 204 
defines which particular infusion types, or features, are available to the user of system 
10 14 when configuration database 204 is activated. In a preferred embodiment of the 
present invention, patient care system 14 is capable of supporting a wide variety of 
such features, ranging from simple primary infusions used for hydration and keep- 
vein-open (KVO) applications to complex multichannel delivery applications. FIG. 4 
illustrates some of the various features or infusion types that are supported by patient 
15 care system 14 according to one embodiment of the present invention. These features 
include, but are not limited to, Dmg Calc 402, Primary/Secondary 404, Delayed Start 
CDel Start) 406, Multi Dose 408, Total Parenteral Nutrition (TPN) 410, Multi Step 
412, and Miilti-Channel Coordinated Infusion CMCCT) 414. As mentioned previously, 
each of these features or infusion types may be implemented by a particular protocol 
20 stored in protocols module 230. The foregoing features are described briefly below; 
see U.S. Patent No. 5,713,856 for a more detailed description of each. 

Dmg Calc 402 is a feature that allows calculation of drag infusion 
paranieters such as rate or dose, based on patient weight, time units, and dmg 
concentration. For example, the drug calculation function of the system allows the 
25 user to either: enter the desired drug dose and the infusion pump functional unit 

microprocessor calculates the correct flow rate to achieve the desired dose; enter the 
desired flow rate and tfie pump functional unit calculates the corresponding drug dose; 
or enter the desired bolus dose and the duration and the pump functional unit 
calculates the bolus rate and the VTBI. The system may additionally include a 
30 pediatric drug calculation function 424 which allows the user to enter, for example, 
flow rate, dose, and diluent volume. From these user entered parameters, the system 
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ejaculates the amount of drag to admix with the diluent to achieve a drug 
concentration consistent with the selected dose and flow rate. Additional details 
regarding Drug Calc 402 features are found in U.S. Patent No. 5,713,856. 

Typically, Dnig Calc 402 mode is used to ensure accuracy of infusion rate data 

5 where a user enters at least a portion of the infusion program data manually, e.g. 
through a touch screen or a keypad. For example, Dmg Calc 402 may be used in 
conjunction with a drag-specific protocol such as stored in a configuration database. 
Alternatively, Drag Calc 402 feature may be used in combination with a stored 
protocol that is identified by a coded label to calculate missing parameter values or to 

10 recalculate new values (e.g. when a prescription includes a deviation from the standard 
protocol values). 

Pri/Sec 404 feature allows use of protocols utilizing a primary infusion 
in conjunction with a secondary infusion solution. Historically a primary infusion 
with an antibiotic secondary would be programmed by entering the primary and 

15 secondary rate and VTBL In the present invention, a user can simply select the 

appropriate antibiotic regimen from the list infusion protocols and have the appropriate 
parameters automatically retrieved. The user may then simply confirm the parameters 
and start the infusion. 

Delay Start 406 delays the start of an infusion protocol or other 

20 treatment for a particular duration of time or until a particular time of day. 

Alternatively, start may be delayed until the happening of a particular event. Such 
events include, but are not linaited to, a signal from the interface unit in response to 
measvired vital signs or other physiological parameters, completion of a stage of 
treatment by another module, or a signal or data received by system 14 over network 

25 10. 

Multi Dose 408 allows multiple doses of a drag to be delivered over 
thne. A protocol incorporating the Multi Dose 408 feature typically includes 
parameters for infusion rate, volume/dose, dose interval, number of doses and start 
time. As with all other protocols stored in a configuration database, a stored Multi 
30 Dose 408 protocol may be selected or activated from the configuration database 
simply by scanning a coded drag label containing the protocol identifier (with or 
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without instructions for deviating from the default protocol values). Any missing or 
different values may then be entered by the user. 

TPN 410 provides for total perenteral nutrition delivery using standard 
or custom ramp and taper protocols known to those skilled in the art. For example, a 
5 typical TPN protocol for delivering 2500 calories over an eight hour period utilizes an 
initial slow rate of delivery with a gradual increase to a maintenance rate for a period 
of six to seven hours, then a gradual decrease to complete the infusion. 

Multi Step 412 is similar to TPN 410 in that it allows delivery of a 
substance at various rates/volumes during a protocol. Standard 430 defines standard 
10 multi-step protocols that are commonly used without deviation for different patients. 
Custom 432 defines multi-step delivery protocols that are customized for particular 
situations. For example, a custom multi-step protocol may be used for delivery of 
dobutamine to increase heart rate during a stress test. Such a protocol typically varies 
the delivery profile of the drag to a patient over time, and patient weight or age is used 
15 as a factor to select a particular profile. Any number of custom multi-step protocols > 
may be defined and used by one skilled in the art. 

MCCI 414 may be used in conjunction with Multi Dose 408 and/or 
Delay Start 406 features to program complex coordinated infusion involving different 
solutions being infused from multiple modules, or channels. FIG. 5 illustrates a 
20 process flow for manually setting up a typical multichannel coordinated infusion 
according to the present invention. After the MCCI 414 function is selected in step 
500 from a menu of operations displayed by the interface unit, the user is prompted to 
enter maintenance rate / volume 502. The user is then queried as to whether a flush 
504 is desired. If yes, the user is prompted to enter flush volume and duration in step 
25 506 before going to step 508. If no fliish, or after flush volume and duration are 

entered, the user is prompted to choose continuous or between doses 508. The user is 
then prompted to confirm the maintenance settings 510. The user then selects a 
chaimel to use for the coordinated infusion in step 512. Step 514 queries the user as to 
wheflier a multi-dose infusion is desired. If multi-dose is to be used for that chaimel, 
30 the user enters the multidose parameters in step 5 16; if multi-dose is not to be used, 
the user is prompted to enter delayed start time in step 518. If a dilution 520 will be 
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used, the user is prompted to enter dilution rate or volume 522, After all parameters 
have been entered for that channel, the user is queried in step 524 as to whether 
additional infusions/channels are to be used. If so, steps 512-520 are repeated until all 
channels are configured. Once all channels are configured, the user is prompted to 

5 start the MCCI 526. 

According to a preferred embodiment of the present invention, some or 
all of the process steps shown in FIG. 5 and the values to be entered may be defined by 
a protocol stored in a configuration database. In such a case, the steps of FIG. 5 may 
be replaced by simply scanning a coded label including the protocol identification, or 

10 altematively by selecting the desired protocol from a nienu, and verifying the 
parameter values. 

One skilled in the art will appreciate that the features and infusion types 
shown in HG. 4 is intended to be illustrative of the present invention, and that patient 
care device 14 may support additional or different features than those described herein. 

15 In a preferred embodiment of the present invention, a plurality of 

patient care systems 12 are linked through a local area network (LAN) to a floor or 
unit server as shown in FIG. 6. For example, in a neonatal intensive care unit (NICU) 
having an NICU server 610, a plurality of bedside patient care devices 650, 652, 654 
and 656 are connected through a LAN 620 to unit server 610, Similar netwoik servers 

20 may be provided throughout the hospital, such as pediatrics 612, intensive care unit 
(ICU) 614, surgery (OR) 616 and oncology 618. Unit server 610 may contain the 
configuration database information for that particular unit. The configuration 
databases in patient care device 12 could be updated periodically by downloading 
them ft-om the unit server. Altematively, a particular configuration database could be 

25 downloaded from the server as it is selected for use in patient care system 650, 652, 
654 or 656. Still another alternative is to have a unit- or department-specific 
configuration database that is automatically downloaded into a patient care system 
650, 652, 654, 656 when the system is operatively connected to the department LAN. 
In any case, having some or all of the configuration database information stored in the 

30 unit server 610, 612, 614, 616, 618 facilitates management and updating of the 

databases. U.S. Patent No. 5,718,442 to Engleson et al., which is incorporated herein 
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by reference, describes a system for connecting bedside naedical devices to a hospital 
network, or network of networks, that may be suitable for use with the present 
invention. 

In yet another an alternative embodiment of the present invention, 
5 patient care device 12 is not directly connected to network 10. Rather, information is 
indirectly connected to network 10 using data input device 60, user interface 54, 
auxiliary interface 62 or other communication means. Such cormnurdcation means 
include, but are not limited to, RS232 Uxiks, MIB systems, IR links, WLANS, portable 
data assistants, memory cards, portable storage media or any other suitable 
10 communication means. Indirect communication can also be accomplished, for 

example, using modems with either tihie traditional phone system, voice over data or 
with cellular phones. In one example, a portable computer such as a personal data 
assistant may be used to transfer database information and/or infusion instractions 
from pharmacy system 34 to patient care device 12. The various possible means of 
IS direct and indirect communication allow information to be continuously or 

periodically transferred between the patient care device and other systems in network 
10 (e.g. pharmacy system 34, unit station server 46, laboratory 42, etc.)- 

Referring again to FIG. 1, regardless of how patient care device 12 
connects to or otherwise communicates with network 10, a feature of the present 
20 invention is that information is transferred, at least occasionally, betwera the various 
departments and systems within network 10 such that functionality of patient care 
device 12 is altered by information received from the other systems. Such a 
distributed, coordinated care system provides for efficient utilization of assets and 
inq)roved quahty of patient care by maximizing integration and utility of information 
25 from various sources in the system and by limiting opportunities for human error. As 
discussed above, one example of how patient care device 12 may alter its personality 
based upon information received from other sources is selection of specific 
configuration database defining a particular, treatment location-specific (e.g. NICU, 
Pediatrics, ICU, Surgery, Oncology, etc.), operating environment for the device 12. 
30 Similarly, prescription information, patient treatment history, drug incompatibilies, 
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etc. from Pharmacy 34 are utilized to program device 12 and minimize data entry 
errors. 

Other communications between patient care device 12 and the various 
departments or units 36, 38, 40, 42, 44, 46, 48 within network 10 serve to enhance 

5 overall quality of care. For example, communication with the biomedical engineering 
department (Biomed 40) helps insure device 12 safety and efficacy and optimize the 
efficient utilization of assets. Asset location can be accomplished by querying devices 
about their serial number and location. As mentioned above, device 12 location can be 
automatically determined by the device's connection to the network or some other 

10 means of identifying itself and its location to the network. Preventative maintenance 
procedures and device diagnostics can be performed remotely and blindly to tiie user. 
When problems occur, diagnostic analysis of perspective device behavior can be done 
remotely. This information can also be collected as a quality control device on an 
ongoing basis. Device utilization data can be collected to optimize the distribution of 

15 devices. As product updates or maintenance procedures come due, notices could be 
posted on the devices' s user interface indicating the pending need. Similarly 
utilization of resources may also be managed from Central Supply 44. Hiey can 
benefit from the same effects as the biomed group. The location and use of medical 
devices can be monitored and optimized based upon this data. 

20 When a patient is first admitted in the Admissions department, a variety 

of data relevant to the patient is entered into the hospital's information system 
including patient sex, size, weight, medical condition, drug allergies, etc. This 
information can be used by the medical device 12 to advise the user of potential 
problems such as adverse drug reactions, incompatible dosing regitnens and unlikely 

25 drag prescriptions. These could appear as prompts to the direct care giver or as flat- 
out restrictions for use beyond prescribed parameters. In patient monitoring 
applications it might include recommended alarm limits, monitoring periodicity, etc. 

A Billing department 38 may rely on information regarding utilization 
of the medical device, particularly the documentation of its use or the delivery of 

30 specific medications, to effect the billing to the customer. The ability to track activities 
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independent of their actual origin offers a way of cross checking them with the 
resultant improvement in efficiencies. 

Networked computer terminals in Unit Stations 46, such as in a nurse's 
station in a particular hospital unit, aUow care providers to assess remotely from any 

5 location connected into the distributed coordinated care network 10, the course of care 
and patient vital signs. The parameters of care (flow rate, PCA parameters, dose, 
monitoring intervals, alarm limits, etc.) can be altered from any location in the 
network, with the necessary authorization. The history of device readings, infusion 
site monitoring and back pressure readings, as well as the infusion and revised 

10 parameters and monitoring limits, can be reviewed remotely. 

By way of non-limiting example, the use of the patient care system 
according to the present invention is explained in greater detail below by reference to 
procedures for configuring patient care device 12 for providing a prescribed treatment 
to a patient 

15 Most hospitals conunonly have an established formulary of medications 

which defines how the medications are typically dispensed. When a patient care 
management system according to the present invention is first installed, a hospital 
committee may be formed to detemnne how that formulary would be applied to the 
patient care devices 12. The configuration definitions (e.g., by hospital unit such as 

20 ICU, NICU, Pediatrics, Oncology, Surgery, etc.) are agreed upon and the drugs and 
typical infusion protocols are established. In addition, all outer limit, or guard rail, 
conditions are defined. This information is entered into a drug library editor and 
configuration management program such as INFUSION MANAGEMENT SYSTEM 
(Alans Medical Systems, San Diego, CA). 

25 When all of the definitions are complete, then a configuration can be 

released. Pumps at the institution are then updated by transferring the configuration 
databases into some or all of their pumps. Transfer of the database information 
typically occurs over network transmission channel 34. Alternatively, databases may 
be downloaded/updated using removable media, portable computers, personal data 

30 assistants, or any other appropriate means for transferring information to patient care 
device 12. 
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Assuring that tiie medication is being administered to the correct patient 
is a key element of this system. Upon entering the hospital every patient is typically 
issued an identification number (patient ID) and an associated wrist band Printed on 
the band or located within the band is the patient ID in text form and in coded form. 
5 Various options exist for the coded ID. For example, the band could utilize a bar code, 
a magnetic strip, or any other means of storing coded patient identification 
information. The desired configuration database might also be recorded on the wrist 
band. For example, a child may have a band with an indicator that the pediatric 
configuration database is to be used. 
10 The process steps involved in configuring a device to utilize a particular 

configuration database according to one embodiment of the present invention are 
shown in FIG. 7. After power to device 12 is tumed on 700 and an internal systems 
check 704 is performed, the device displays on user interface 54 information 
pertaining to the current patient and/or the current location 708. In one embodiment of 
15 the invention, this information is recalled from the last use of the device. 

Alternatively, the device location and or patient identification may be detennined by 
information received through its connection to network 10 and/or a LAN within the 
hospital. For example, referring to FIG. 5, a device 650 connected over LAN 620 to a 
server in NICU 610 receives information from the server that it should be located by 
20 Bed 1, and that a particular patient is scheduled to be in that bed. Accordingly, the 
device 650 utilizes that information as the default patient and location. Alternatively, 
device 650 automatically determines its location within the hospital by a sensor or 
other means of uniquely deterniining its location. A sensor is defined broadly herein as 
any device or process of sensing or detecting the location of a device, including, but 
25 not limited to, a network receptacle or port address, a network adapter, programmed 
location instractions, hospital records indicating location, an IR sensors or tags, RF 
sensors or tags, magnetic sensors or tags, or any other means of detecting the location 
of a device 650. 

In step 712 the device queries the user whether the patient information 
30 is correct. If the patient is new to the device, or if the information is missing or 
incorrect, the user enters the patient ID in step 716. Patient ID is typically entered 
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using input device 60, e.g., by scanning a patient's coded wristband including patient 
identification information. Alternatively, patient ID may be entered manually using a 
keyboard, keypad, or other interface device 54. If the current configuration database is 
missing or incorrect 720, the user is prompted to select the appropriate configuration 
5 database 724 (e.g. according to location, patient, physician, etc.). Altematively, the 
appropriate configuration database ID may scanned into the system from the patient's 
identification band, or may be automatically retrieved from memory or from another 
location in network 10 once the patient identity, location or other patient-specific 
information is entered into device 12. 
10 When a physician orders an IV, the order is typically first sent to the 

pharmacy (where it is entered into the hospital's pharmacy system 34). Most hospitals 
include a pharmacy computer system capable of maintaining records of medications 
already given as well as those prescribed in the future. Most commercially available 
pharmacy systems allow for adverse drag interactions to be checked for as part of the 
15 process prescription entering/drug dispensing process. 

According to a preferred embodiment of the present invention, after the 
order is entered the prescription is prepared. If the drag is compounded or sourced in 
the pharmacy, then the prescribed medication is prepared and placed in a container. 
Pharmacy system 34 would then translate the infusion order from the hospital 
20 pharmacy software onto a label with encoded message and accompanying text The 
label preferably includes at least the following information: patient ID, infusion 
protocol reference, infusion protocol deviations, or deltas, if any, and scheduled time 
of infiision. The label is affixed to the medication container before the prescription is 
transported to the unit nursing station. Medications are preferably transported from 
25 the Pharmacy to the nurse's station by hospital personnel or contained within drag 
dispensing cabinets near the nurse's station. Altematively, drags may be transported 
using a robotic system, such as a PYXIS system (Pyxis Corporation, San Diego, CA). 
If the drag is to be distributed from a unit nursing station, then the same type of label 
may be printed at the station and affixed to the drag container. 
30 At an appropriate time, the labeled medication container is then taken 

to the patient's location. The bar code reader (or other data input device) is used to 
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scan the coded drug label, the patient's coded ID band and the caregiver's 3D badge, 
and optionally supplementary prescription information or medical device configuration 
instructions (including configuration database ID) printed on the label or an 
accompanying order. The scanned information is stored in memory 58, while device 
5 12 first compares the scanned data to ensure that the patient identity corresponds to the 
patient information on the medication label, and that the prescription is being 
administered at the appropriate time. After the correct patient, prescription and time 
are verified, device 12 recalls firom the active configuration database the protocol or 
other program information identified on the container label. The default parameter 
10 values are adjusted by any delta information included in the prescription. The user is 
prompted to enter, using a touch pad, bar code reader, or any other appropriate means, 
any missing or incomplete data. Optionally, some data may be obtained automatically 
from network 10 or fix>m the appropriate department server based upon the entered 
patient ID, caregiver ID, user commands, etc. Once all required settings have been 
15 entered, central imit 14 displays the values, either serially or in one or more groups, to 
the user for verification. Once all information is entered and verified, interface unit 
programs the functional module(s) to perform the prescribed treatment 

It should be noted that the prescription label or other treatment 
instmctions may identify multiple protocols and other instmctions. ITie multiple 
20 protocols (or a single complex protocol), may define a plurality of operations to be 
performed by device 12. For example, the prescription label or prescription order 
could identify a multichannel coordinated infusion protocol involving multiple 
channels and infusion solutions. Additionally, the same order may identify a protocol 
for (or detail instmctions for) programming a functional module or auxiliary device to 
25 monitor the patient physiological parameters, such as a blood pressure, heart rate, 02 
saturation, respiratory rate, etc. Interface unit 14 monitors the measured parameters 
and, depending upon active rule sets and other configuration instructions, can modify 
infusion parameters based upon signals received firom the physiological monitors. 
Such feedback systems may be useful for titration of dmgs, to control anesthesia, or to 
30 regulate blood pressure. 
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Various embodiments of the invention have been described. The 
descriptions are intended to be illustrative, not limitative. Thus, it will be apparent to 
those skilled in the art that modifications may be made to the invention as described 
without departing from the scope of the claims set out below. 

5 
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WHAT IS CLAIMED IS : 

1 . A patient care system comprising: 

a patient care device including a memory for storing a plurality of 
5 configuration databases, each of said configuration databases comprising a plurality 
of device operating parameters; 

a network communicating with said device, said network including at least 
one database comprising patient-specific information; and 

means for activating a configuration database from said plurality of 
10 configuration databases based at least in part on said patient-specific information 
communicated to the care device, wherein the patient care device operates in 
accordance with at least one of said plurality of groups of operating parameters of 
the activated configuration database. 

15 2. The system of claim 1 , wherein said network comprises a plurality of 
separate databases communicating via manual interaction. 

3. The system of claim 1 , wherein said network comprises a plurality of 
separate databases communicating via automated interaction. 

20 

4. The system of claim 1, wherein concununication between the network and 
care device is provided by a coded data input device or a network connection. 

5. The system of claim 1, wherein the patient-specific information comprises 
25 any of a patient identifier, a patient location, a patient care device location, patient 

age, a physical characteristic or a medical characteristic. 

6. The system of claim 1, wherein the activating means comprises: 
a processor within said patient care device; 

30 a patient-specific information input device in communication with said 

processor; and 
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a computer piogram stored in said memory, said computer program 
executable by said processor and including instructions for activating the specific 
configuration database firom said plurality of configuration databases based at least 
in part on input patient-specific information. 

5 

7. The system of claim 6, wherein the patient-specific information comprises a 
patient identifier, patient location, patient care device location, patient age, a 
physical characteristic, a physiological characteristic, a psychological characteristic, 
patient medical history, a patient medical record, a patient diagnosis, or a care 

10 provider identifier. 

8. The system of claim 6, wherein said input device is a coded data input 
device or a network connection. 

15 9. The system of claim 1, wherein said selecting means comprises a patient 
care device location sensor, such that selection of the specific configuration 
database is based, at least in part, on a location of the patient care device. 

10. The system of claim 1, wherein the operating parameters within at least one 
20 of said plurality of configuratiion databases are organized into a plurality of groups. 

11. The system of claim 10, wherein at least one of said plurality of groups is a 
protocol defining parameters for operating said patient care device to deliver a 
substance to the patient. 

25 

12. The system of claim 1, wherein at least one of said configuration databases 
comprises a plurality of drug delivery protocols, at least one of said protocols 
including a protocol identifier and at least one default parameter value for 
programming the patient care device to deliver a drug. 

30 

13. The system of claim 12, further comprising: 
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a coded data input device operadvely connected to said patient care device; 

and 

a drug container having a label comprising coded patient care instructions, 
wherein the data input device is capable of reading the coded patient care 
5 instructions from the label into said patient care device. 

14. The system of claim 13, wherein the coded patient care instructions 
comprise the protocol identifier, such that reading the coded patient care 
instructions activates the protocol identLBed by the protocol identifier. 

10 

15. The system of claim 14, wherein the coded patient care instmctions further 
comprise a deviation from the default parameter, such that the patient care device is 
programmed to deliver the drug in accordance with the deviated parameter. 

15 16. The system of claim 1, wherein the patient care device comprises any of an 
infusion pump, a syringe pimip, a patient-controlled analgesia pump, an epidural 
pump, an enteral pump or a physiological monitor. 

17. The system of claim 1, wherein tfie patient care device comprises an 
20 interface unit and at least one functional unit detachably and operatively connected 
to the interface unit, wherein the interface unit includes said memory and said 
functional unit provides care to the patient in accordance with said at least one of 
said plurality of configuration databases. 

25 18. The system of claim 17, wherein the functional unit comprises any of an 
infusion pump, a syringe pump, a patient-controlled analgesia pump, an epidural 
pump, an enteral pump or a physiological monitor. 

19. A patient care system comprising: 
30 a patient care device comprising a processor and a memory, said memory 

storing a plurality of configuration databases, said patient care device capable of 
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providing patient therapies or monitoring the condition of a patient in accordance 
with operating parameters defined by a configuration database selected from said 
plurality of configuration databases; and 

an input device conomunicating with said patient care device, said input 
5 device adapted to enter patient-specific information into the patient care device, 

wherein the processor selects the first configuration database from said 
plurality of configuration databases in response to the patient-specific information 
entered into the patient care device through the input device. 

10 20. The patient care system of claim 19, wherein the input device is a coded 
data input device. 

21. The patient care system of claim 20, wherein the coded data input device is 
a bar code reader. 

15 

22. The patient care system of claim 20, wherein the coded data input device is 
any of a magnetic media reader or a voice recognition device. 

23. The patient care system of claim 19, wherein the input device is a network 
20 connection. 

24. The patient care system of claim 23, further comprising a network, said 
network comprising at least one database in communication with said network 
connection of said interface unit via manual interaction or automated interaction. 

25 

25. The patient care system of claim 24, wherein said network connection is a 
wireless network connection. 

26. The patient care system of claim 19, wherein the patient-specific 
30 information comprises a location. 
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27. Hie patient care system of claim 26, wherein the location is any of a 
location of the patient, a location of the patient care device, or a network address. 

28. The patient care system of claim 19, wherein said patient care device 
5 comprises: 

an interface unit including the processor and the memory, said interface unit 
in conMnunication with the input device; 

a functional unit communicating with the interface unit, said functional for 
providing the patient therapies or monitoring the condition of a patient in 
10 accordance with the operating parameters defined by the selected configuration 
database. 

29. The patient care system of claim 28, wherein said functional unit is 
removably connected to said interface unit. 

15 

30. The patient care system of claim 28, wherein the functional unit is any of an 
infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a 
blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a 
heart rate monitor or an intracranial pressure monitor. 

20 

31. A patient care system, comprising: 

an interface unit comprising a processor and a memory, said memory 
storing a plurality of configuration databases; 

an input device conmiunicating with said interface unit, said input device 
25 adapted to enter patient-specific information into the interface unit; 

a functional unit removably connected to the interface unit and 
communicating therewith, said functional unit capable of providing patient 
therapies or monitoring the condition of a patient in accordance with a 
configuration database selected from the plurality of configuration databases; and 
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a network communicating with said interface unit, said network including at 
least one database comprising the patient-specific information and communicating 
with said interface imit via manual interaction or automated interaction, 

wherein the processor selects the configuration database from said plurality 
5 of configuration databases in response to the patient-specijac information entered 
into said interface unit through said input device, and said functional unit provides 
a patient therapy or monitors the condition of the patient in accordance with the 
selected configuration database. 

10 32. The system of claim 3 1 , wherein the input device comprises a network 
connection or a coded data input device. 

33. Hie system of claim 31, wherein the functional unit comprises a pump for 
delivering a drug or fluid to a patient, wherein said functional unit delivers said 

15 substance in accordance with the selected configuration database. 

34. The system of claim 31, wherein the selected configuration database 
comprises at lease one protocol for operating said functional imit, such that the 
functional unit operates in accordance with the protocol to provide a patient therapy 

20 or to monitor the condition of the patient. 

35. The system of claim 31, wherein the patient-specific information is any of a 
location of the patient, a location of the interface unit, a network address, or a 
patient medical characteristic. 

25 

36. A method of providing care to a patient, comprising: 

activating a configuration database from a plurality of configuration 
databases stored in a memory of a patient care device, said patient care device 
capable of providing patient therapies or monitoring the condition of a patient in 
30 accordance with the activated configuration database, wherein said configuration 

29 

BNSDOCID: <WO__02069099A2J_> 



wo 



02/069099 



PCT/US02/05667 



database comprises at least one protocol defining parameters for operating said 
patient care device; 

configuring said patient care device to operate in accordance with said 
activated configuration database; 
5 selecting the patient care protocol from said activated configuration 

database; 
and 

operating said patient care device in accordance with the operating 
parameters defined by the selected protocol to provide care to the patient. 

10 

37. The method of claim 36, wherein the input device is a coded data input 
device or a networic coimection. 

38. The method of claim 37, wherein activating the configuration database 
15 comprises positioning the patient care device at a location in a network of 

computers, such that the active configuration database is selected as a fvmction of 
said location in the network. 

39. The method of claim 36, wherein activating the configuration database 
20 comprises: 

entering patient-specific information into said patient care device using an 
input device communicating with said patient care device; and 

selecting the configuration database from said plurality of configuration 
databases based at least in part on said patient-specific information. 

25 

40. The method of claim 39, wherein the patient-specific information is any of a 
location of the patient, a location of the patient care device, a network address, or a 
patient medical characteristic. 

30 

30 
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41. The method of claim 36, wherein activating a configuration database 
comprises selecting a configuration database from a menu of configuration 
databases using an input device in communication with the patient care device. 

5 42. The method of claim 36, wherein selecting a patient care protocol 

comprises entering a protocol identifier corresponding to said patient care protocol 
using an input device in conomunication with the patient care device. 

43. The method of claim 42, wherein said patient care protocol includes a drug 
10 identifier and at least one drug delivery parameter. 

44. The method of claim 43, wherein said at least one drug delivery parameter 
is any of a concentration, a container size, a dose, an bolus dose, a dose rate, a 
maximum dose rate, a minimum dose rate, a maximum cumulative dose, a volume 

15 or an adverse dmg identifier. 

45. The method of claim 36, wherein selecting a patient care protocol 
comprises selecting the protocol from a menu of protocols displayed on a user 
interface of said patient care device using an input device in communication with 

20 said patient caie device. 

46. The method of claim 36, wherein said patient care device comprises: 
an interface unit comprising tiie memory and a processor; 

an input device in communicating with the interface unit, said input device 
25 adapted to enter patient-specific information into the interface unit; and 

a functional unit communicating with the interface unit, said functional unit 
for providing the patient therapies or monitoring the condition of a patient in 
accordance with the activated configuration database. 

30 47. A method of progranmaing a patient care device to deliver a substance to a 
patient, comprising: 

31 
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10 



printing a coded label, said label including a substance delivery protocol 
identifier; 

attaching the label to a container holding the substance; 

transporting the container to the patient care device; 

entering the protocol identifier into the patient care device; 

retrieving firom a memory in the patient care device a specific protocol 
identified by the identifier, said specific protocol comprising a plurality of deUvery 
parameters and default values; and 

progranmiing the patient care device to deliver the substance to the patient 
in accordance with the specific protocol. 



48. The method of claim 47, further comprising selecting a configuration 
database from a plurality of configuration databases stored in the memory of the 
patient care device, wherein the selected configuration database includes the 
15 specific protocol. 



49. The method of claim 48, wherein the selected configuration database further 
includes additional information defining an operating environment for the device, 
said information comprising any of a protocol, a rule set, a device operating limit or 

20 a device operating feature. 

50. The method of claim 48, wherein selecting the configuration database 
comprises transferring patient-specific information to said patient care device to 
enable selection of the configuration database firom said plurality of configuration 

25 databases based at least in part on said patient-specific information. 

5 1 . The method of claim 50, wherein transferring of said patient-specific 
information comprises entering the patient-specific information into the patient care 
device using a coded data input device or a network connection. 

30 
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52. The method of claim 51, wherein said entering step comprises scanning the 
coded label with a coded data input device operatively connected to said patient 
care system, 

5 53. The method of claim 52, wherein the data input device is a bar code reader. 

54. The method of claim 48, wherein selecting the configuration database 
comprises positioning the patient care device at a location in a network of 
computers and selecting the configuration database as a function of said location. 

10 

55. The method of claim 45, wherein the coded label further includes a value 
representing a deviation from the specific protocol, such that the prograrmiiing step 
includes programming the patient care device to deliver the substance to the patient 
in accordance with the deviation from the specific protocol. 

15 

56. The method of claim 45, wherein the coded label further includes 
supplementary information, said information including a patient identifier, a 
deviation from the first protocol and a scheduled time to begin delivery of the 
substance to the patient. 

20 

57. The method of claim 56, further comprising: 

scanning a patient identification code attached to the patient; 

confirming that the patient identifier on the container label corresponds to 
the patient identification code; and 
25 entering the supplementary information from said coded label, 

wherein the step of programming the patient care device comprises 
programming the patient care device to deliver the substance to the patient in 
accordance with the deviation from the specific protocol at the scheduled delivery 
time. 

30 
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58. The method of claim 57, further comprising scaiming a provider 
identification code. 

59. A method of delivering a drug or fluid to a patient, comprising: 

5 obtaining patient-specific information fi<om a database in a hospital 

network; 

transferring the patient-specific information to a patient care device using an 
input device in communication with said patient care device, said interface unit 
comprising a memory storing a plurality of configuration databases for configuring 
10 the care device to provide care to a patient; 

activating a configuration database firom the plurality of configuration 
databases in response to said patient-specific information, the activated 
configuration database including a plurality of protocols; 

selecting a protocol firom said plurality of protocols, said protocol including 
15 at least one parameter for programming the care device to deliver a drug or fluid to 
the patient; 

progranmiing said device to deliver the drug or fluid to the patient in 
accordance with the selected protocol; and 

delivering the drag or fluid to the patient in accordance with the selected 
20 protocol. 

60. The method of claim 59, wherein said patient care device comprises: 

an interface unit including the memory and a processor, said interface unit 
in conomunication with the input device; and 
25 a functional unit removably connected to said interface unit and 

conmiunicating therewith, said functional unit including a pump for delivering the 
drag or fluid to the patient. 
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(57) Abstract: The present invention is directed to a system and method for providing care to a patient, comprising a patient care 
device (12) having a number of configuration databases stored in a memory in the device. Each configuration database preferably 
includes protocols, operating limits, rule sets and/or operating features that collectively define an operating environment, or person- 
ality, of the device. Selection of a specific configuration database preferably is based at least in part upon patient-specific information 
obtained from any location in a distributed hospital network. In preferred embodiment, programming a patient care device to deliver 
a drug to a patient entails activating a configuration database and scanning a machine-readable drug label identifying a particular 
protocol stored in the activated database. The selected protocol includes default parameters for delivering the drug, and the label 
optionally includes instructions for deviating from the default protocol. 
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